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REMARKS 

Applicants have amended the paragraph located on page 28, line 3 to line 
21, of the Specification to correct a minor typographical error. Claims 1-30, 32- 
46, and 48-51 have been amended. Claim 47 has been cancelled and Claims 52-82 
have been added. Accordingly, Claims 1-30, 32-46, 48-82 are pending in the 
application. The reconsideration of the application is respectfully requested. 

In the July 17, 2002, Office Action, the Examiner objects to the claims 
because of the absence of Claim 31 which caused inconsistent claim numbering 
following Claim 30. The Examiner has renumbered Claims 1-51 as claims 1-50. 
Notwithstanding the missing claim 31, Applicants respectfully submit that Claims 
1-51 should remain as originally numbered in the original application and that new 
claims should be numbered beginning with the number next following the highest 
numbered claim presented, which is Claim 52. This is consistent with Patent 
Office Practice and as stated in 37 C.F.R. 1.126 "When the apphcation is ready for 
allowance, the examiner, if necessary, will renumber the claims consecutively". 
However, should the Examiner persist in renumbering the Claims, Applicants will 
fiilly comply with Examiner's requests in this regard. Accordingly, the newly 
presented claims are numbered as Claims 52-82. 

Claims 1-30, 32-46, and 48-51 stand rejected under 35 U.S.C. Section 
102(e) as being anticipated by Schutzer (U.S. Patent No. 6,292,789). Schutzer 
discloses a method and system for presentment of bills wherein the biller account 
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automatically foraiats a bill to conform to standard bill definition language for a 
consumer and automatically stores the formatted bill in a storage location, such as 
a commerce document server (CDS) (see Schutzer Abstract and Figs. 1-7). More 
specifically, a bill service provider (BSP) formats the bill and places the bill 
directly in the biller's mailbox for electronic mailing. Then, a consumer service 
provider (CSP) accesses the electronic bill produced by the bill service provider, 
along with other bills for the consumer, stores the bill(s), and presents the bill(s) to 
the consumer. Schutzer, therefore, provides a method and system that enables a 
plurality of inter-related entities and applications to interact with each other to 
provide electronic bill presentment and payment. Billing information are 
transferred fi-om the billers to a BSP, fi-om the BSP to a CDS, fi-om the CDS to a 
CSP, and then finally from the CSP to the consumer. These separate entities and 
applications are authenticated by another entity, the certificate authority (see 
Schutzer Figs. 1-7). As can be seen, the billing information is routed through 
multiple applications and entities before it is finally presented to the consumer. In 
addition, because of the limitation with coordinating interactions between multiple 
entities and applications, Schutzer provides a system in which incoming billing 
data is processed without transformation before it is presented to the consumer. 
Schutzer, in fact, formats the bills into a standard bill definition language to 
prepare it for routing through multiple entities and applications. 

In contrast, the present invention provides an end-to-end electronic bill 
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presentment and payment (EBPP) system that communicates in lingua franca to 
enable any and all billers to interface with each other to cooperatively present and 
accept payment of bills using a "rules application process [that] uses a special 
rules development language ... to generate a translator that parses the biller's data 
stream into a common document model tree. In the tree, the data and their 
attributes are mapped into nodes which fit the common document model for 
storage in the data base. Because of the generic and universal nature in which the 
billing data and its attributes are stored, the database can be coupled to 
presentment processors that may include style sheets and other applications that 
transform the stored data into whatever desired form and format to support bill 
presentment wherever and whenever desired." (see Applicants* Specification, page 
9, lines 10-19). In other words, a common format document model is used to 
transform data and attributes into a form that can be stored in a common format 
storage model before the data is processed (see Applicants' Specification, page 8, 
lines 17-18). Storing the transformed data before processing allows the present 
invention (1) to efficiently present the bill to the consumer; (2) to query the stored 
data; (3) to control how it will be presented (e.g., brand building); and (4) to use 
the stored data as a customer service^ tool (e.g., help desk) (see Applicants* 
Specification, page 10, lines 3-7). The use of the common format document 
model and the universality of its structure allows the billers to maintain control, 
from a billing console functionality, over their billinR data and how it is presented 
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on any desired platform using any desired applications, formats and protocols (see 
Applicants* Specification, page 10, lines 14-16). For example, "the database can 
simultaneously present bills for different customers from a single batch of bills in 
various spoken languages, on HTML based browsers, on OFX supported 
applications, or in any other v^ay desired by any biller or customer" (see 
Applicants* Specification, page 10, lines 20-22). Applicants' common model 
document processing functionality provides for a generic conversion process that 
is not confined to a particular industry, biller, or type of customer . Consequently, 
these features allow billers to, among other things, leverage and build brand, in 
addition to providing billers with the ability to control the way the bill looks, what 
is contained in the bill and why, and how and according to what terms the bill can 
be paid (see Applicants' Specification, page 11, lines 12-15). 

Claims 1, 10, 17, 18, 41, 45, 46, 48, and 50 stand rejected under 35 U.S.C. 
Section 102(e) as being anticipated by Schutzer. Independent Claims 10, 11, 13, 
17, and 18 have been rewritten in dependent form to improve the organization and 
readability of the claims. Specifically, Claims 10, 11, 13, 17, and 18 are now 
dependent upon Claim 1 . 

Claims 1, 41, 45, 46, 48, and 50 distinguish over Schutzer at least by 
reciting a parsing functionality which is adapted to parse billing data from a 
plurality of billers using rules of conversion according to which said parsing 
functionality is programmed, corresponding to a plurality of data types, and to 
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provide relevant information for further use by said system, and a common 
document model processing functionality adapted to transform said relevant 
information into a common document model, said common document model is 
adapted to accommodate said relevant information from said plurality of billers 
and according to said plurality of data types. 

Applicants respectfully traverse the Examiner's assertion that the limitation 
recited in independent Claims 1, 41, 45, 46, 48, and 50 of a "parsing functionality" 
v^hich is adapted to parse billing data from a plurality of billers using rules of 
conversion according to which said parsing functionality is programmed, is 
anticipated by Schutzer. 

In rejecting these claims, the Examiner has presented (1) bill service 
provider, 104, (2) billers, 106, (3) certificate authority, 110, and (4) billing data, 
as disclosed by the Schutzer patent, making reference to the abstract, figs, 1-5, 
and column 13, line 11 to column 14, line 25 of the Schutzer patent (see the Office 
Action dated July 17, 2002, paragraph 4) as evidence of anticipation of the 
"parsing function" of the present invention. Applicants cannot agree v^ith the 
Examiner in view of the evidence presented herein. First, Schutzer's "[b]ill service 
provider 104 is an entity which accepts and consolidates bills for the biller ..." 
(see Schutzer, column 13, lines 20-21). Second, "[t]he certificate authority 110 
[disclosed by Schutzer] is an entity which issues and revokes certificates to 
identify and verify service providers ... provides rules ... for compliance " (see 
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Schutzer, column 13, lines 28-31). The bill service provider and the certificate 
authority are separate entities and provide substantially different functions and 
services. More specifically, the bill service provider is a generic term for an entity 
known in the art to be a location where bills are accepted and consolidated. The 
certificate authority function operates as a login element that verifies the bill 
service provider. For example, the certificate authority may operate as a "security 
administrator" who grants or denies access to the system disclosed by Schutzer. 
Figure 1 of Schutzer clearly shows that certificate authority is one of a plurality of 
entities that makes up Schutzer's EBPP. Furthermore, the "rules" used by the 
certificate authority solely provide for authenticating the identity of senders, 
consisting of bill service providers, consumer service providers and the document 
server (see Schutzer Fig. 1-7). In other words, the certificate authority provides 
rules for authentication to help service providers comply with authentication 
requests before (1) bills are accepted and consolidated by the bill service provider; 
(2) bills are presented to the consumer; and/or (3) payment for the bills are 
accepted from the consumer. Schutzer's certificate authority does not provide a 
procedure or functionality for parsing a biller's data stream according to rules of 
conversion (as will be explained). 

In contrast, the parsing functionality of the present invention, which parses 
billing data using "rules of conversion" to provide structural processing and 
conversion for the common document model for use by the bill presentment and 
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payment system, is a "[rjules based parsing engine 24 [which] allows a wide 
variety of biller data 23 types and formats to be operated on or parsed by rules in 
order to fit a common document or data model which can store and process both 
data and its attributes" (see AppUcants* Specification, page 26, lines 5-7), As 
disclosed by Applicants, the rules of conversion allow the data to be "at least 
easier to generate and correlate the attributes for various data in a form that can be 
used by the common document or data model" (see Applicants' Specification, page 
26, lines 14-16). As can be seen, the "rules of conversion" as embodied by the 
present invention and the "rules of authentication" of Schutzer's certificate 
authority relate to two entirely different functions. The "rules of conversion" of 
the present invention directly affect the function of the parsing engine, the 
common document model, and the incoming data whereas the "rules of the 
certificate authority" are used for compliance to issue, revoke, and verify service 
providers and senders. Furthermore, Applicants see no relationship between the 
bill service provider as disclosed by Schutzer and the parsing function of 
Applicants' invention. Bill service provider is a generic entity that "forwards" bills 
to bill payers or to a commerce document server, as disclosed by Schutzer, to be 
forwarded to bill payers whereas the parsing function of the present invention 
resides in a parsing engine that parses incoming billing data prior to presenting the 
billing information. 
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Applicants also respectfully traverse the Examiner's assertion that the 
common document model processing functionality is anticipated by the evidence 
cited by the Examiner (specifically, Schutzer figs. 1-7, and column 14, line 26 to 
column 15, line 2). Schutzer discloses that the bill service provider converts the 
bill, along with enclosures, to a standard bill definition language (see Schutzer 
column 14, lines 32-35), "The standard bill definition language is an extension of 
hypertext markup language/extended markup language that allows for combining 
templates with data and taking digital signatures (see Schutzer, column 14, lines 
35-38). In short, Schutzer discloses a bill service provider converting bills into a 
standard bill definition format. 

In contrast, as stated in the Applicants' Specification (page 28, lines 9-17): 

"[t]hink of the common document model/data model according to the 
present invention as a list of every field of data, and its attribute (such as, 
for example, bill number and tag denoting bill number) that could occur in 
any bill desired to be presented by any biller. Not every biller data . . . will 
have all of that information; instead, it only has a subset of all data and 
attributes which could be accommodated by the common document 
model/data model. Accordingly, the biller's subset, which contains data 
and attributes which can be stored and processed according to the model, 
but not all of them, is known as the common document model/data model 
tree." 


Therefore, a significant difference between Schutzer and the present invention is 
that Schutzer's standard definition format merely provides an instructional set of 
rules for formatting the bills uniformly based on pre-determined templates. On the 
other hand, Applicants* common document model processing functionality 
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provides a generic conversion process that is "not confined to a particular industry, 
biller, or type of customer" (see Applicants' Specification, page 9, lines 3-5) and 
accepts any subset of data from any biller. Fundamentally, the common model 
processing allows the present invention to aggregate its fields of data to 
accommodate bills from any biller or type of customer (see Applicants' 
Specification, page 28, lines 9-17). For example, a first biller may require one 
particular subset of data while second biller may require a similar subset data in 
additional to another subset of data that is substantially different from the first 
biller. Using the common model processing, the present invention can 
accommodate the first and second biller's individual data set without mandating a 
particular template for both billers. Therefore, billers retain autonomy on how 
they collect, group, display, and present their billing information. In short. 
Applicants' common document model processing functionality solves the problem 
associated with multiple billers having and requiring different information by 
accepting any subset of any data from any biller. 

In view of the distinctions noted and the advantages attendant thereto, it is 
respectfully submitted that Schutzer does not teach every aspect of the claimed 
invention of independent Claims 1, 41, 45, 46, 48, and 50, either explicitly or 
impliedly. Therefore, it is submitted that independent Claims 1, 41, 45, 46, 48, 
and 50 clearly distinguish over Schutzer and are patentable thereover. 

Claim 10 is dependent upon Claim 1 and further distinguishes over 
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Schutzer by reciting "an interactivity functionality adapted to detect and respond 
to communications from said bill payers, by at least (i) retrieving information from 
said database and presenting it to said bill payers in a form requested by said bill 
payers; and (ii) altering information in said database corresponding to said bill 
payers according to said communications." The Examiner cited Schutzer figs, 1-7, 
and column 14, line 26 to column 15, line 2, which discloses that the "bill can be 
sent or "pushed" when available or held and sent when requested, i.e., "pulled" 
(see Schutzer column 14, lines 51-53). The reference, however, does not disclose 
that bills can be presented to bill payers in a form requested by the bill payers as 
claimed. As disclosed by Applicants, "customers can pay ... in a manner where 
each bill is presented to the customer in a way that is specially tailored to the 
customer with graphics, advertising, and other information that has been 
demographically proven to connect with that particular customer" (see Applicants' 
Specification, page 12, lines 13-16). Succinctly, the present invention allows both 
billers and payers to customize and control the presentation of bills whereas 
Schutzer only allows billers to customize bills. Therefore, Applicants respectfiiUy 
traverse the Examiner's assertion of anticipation as to the "interactivity 
ftinctionality" element recited in Claim 10. 

Claims 17 and 18 are dependent upon Claim 1 and fiirther distinguish over 
Schutzer by reciting "a financial source interface adapted to send and receive 
communications to and from at least one financial entity and to alter information 
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in said database (at least in part) according to said financial source 
communications." As to Claim 17, the Examiner refers to Schutzer figs, 1-7, and 
column 14, line 26 to column 15, line 2; however, the Schutzer drav^ings and text 
referenced by the Examiner do not disclose a financial source interface as recited 
in Claim 17. Basically, the financial source interface of the present invention 
establishes a channel of communication with financial entities and provides an 
avenue for updating the database accurately (e.g., upon payment of a bill to 
prevent duplicate bills from being sent or retrieved). 

As to Claim 18, the Examiner also refers to Schutzer figs. 1-7, and column 
14, line 26 to column 15, line 2\ however, the Schutzer drawings and text 
referenced by the Examiner do not disclose a financial source interface as recited 
in Claim 18. Claim 18 further distinguishes over Schutzer by reciting the financial 
source interface sending and receiving communications based at least in part on 
communications firom said bill payers. For example, bill payers can authorize the 
bill presentment and payment system of the present invention to allow a financial 
entity to alter information found in the database (e.g, payers can authorize 
payment of a bill and allow a financial entity to accept and update the database to 
prevent duplicate billing). Based on the foregoing, Applicants respectfully 
traverse the Examiner's assertion of anticipation as to "a financial source interface" 
element of Claims 17 and 18. 
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Independent Claim 41 further distinguishes over Schutzer by reciting "a 
biller interface coupled to said database adapted to allow said plurality of billers to 
identify market segments of said bill payers according to market rules and 
information retrieved from said database." The Examiner cites Schutzer, 25, 
and column 20, lines 15-55 (see Office Action dated July 17, 2002, page 9, line 5); 
however, the Schutzer drawings and text referred to by the Examiner citation do 
not disclose a biller interface as recited in Claim 41. Fig. 25, to which the 
Examiner refers, "is a flow chart which provides further detail regarding the 
process of the consumer transferring to a new consumer service provider for an 
embodiment of the present invention" (see Schutzer column 7, lines 12-15). The 
text in column 20, lines 15-55, describes in further detail figs, 15-16 which provide 
detail regarding the process of payment and the process of acknowledging 
payment, respectively. As can be seen, none of the text or figures relied on by the 
Examiner disclose a biller interface which allows billers to identify market 
segments of bill payers. In short, the portions of the Schutzer patent relied upon 
by Examiner in rejecting claim 41, describe a process of payment and 
acknowledgment of payment that are substantially different from the claimed 
biller interface which further empowers billers with the ability to identity and 
specify market segments. Therefore, Applicants respectfully traverse the 
Examiner's assertion of anticipation as to "biller interface" element of independent 


Claim 41. 
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Independent Claim 45 further distinguishes over Schutzer by reciting, 
generally in the manner of independent Claims 10 and 41, "interactivity 
functionality adapted to detect and respond to communications fi"om said plurality 
of billers regarding market segments of said bill payers by retrieving information 
from said database and altering appearance and content of bills presented to said 
bill payers based on said communications." In rejecting claim 45, the Examiner 
refers to Schutzer, figs. 1-7, and column 14, line 26 to column 15, line 2. 
However, the portions of the Schutzer patent relied on by the Examiner do not 
disclose an interactivity functionality regarding market segments, as claimed in 
Claim 45. Rather, the portions of the Schutzer patent relied upon by Examiner 
describe the flow of information of Schutzer's bill presentment and payment 
system. Moreover, as stated above with respect to Claim 41, the portions of the 
Schutzer patent referred to by Examiner in rejecting Claim 41, namely fig, 25, and 
column 20, lines 15-55, do not disclose an interactivity functionality regarding 
market segments either. In short, the interactivity functionality limitation of Claim 
45 further empowers billers with the ability to customize the appearance and 
content of bills based on market segments retrieved from the data. In view of the 
foregoing, Applicants respectfully traverse the Examiner's assertion of anticipation 
as to an "interactivity functionality regarding market segments" element of 
independent Claim 45. 

Similarly, independent Claim 46 further distinguishes over Schutzer by 
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reciting "interactivity functionality adapted to detect and respond to 
communications from said plurality of billers regarding market segments of said 
bill payers by retrieving information from said database and sending marketing 
messages to said bill payers based on said communications." The Examiner 
makes reference to Schutzer,y?g5. 7-7, and column 14, line 26 to column 15, line 
2. However, the referenced portions of the Schutzer patent relied upon by 
Examiner do not disclose an interactivity fiinctionality regarding market segments 
as claimed in Claim 45. 

In addition, as previously stated with respect to Claim 45, the referenced 
portions of Schutzer relied upon by the Examiner describe the flow of information 
of Schutzer's bill presentment and payment system. Applicants, on the other hand, 
disclose an interactivity frinctionality where billers can send marketing messages 
to payers based on information retrieved from the database. This allows billers to 
capitalize on the information residing on the database. Therefore, in view of the 
foregoing. Applicants respectfully traverse the Examiner's assertion of anticipation 
as to an "interactivity functionality regarding market segments" element of 
independent Claim 46. 

Independent Claim 48 further distinguishes over Schutzer by reciting "an 
agent interface coupled to said database adapted to allow a plurality of agents 
having agency relationships with said plurality of billers to communicate with said 
bill payers regarding bills." The Examiner did not offer any evidence of 
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anticipation for this element. Therefore, Applicants respectfully traverse the 
Examiner's assertion of anticipation as to an independent Claim 48. 

Independent Claim 50 further distinguishes over Schutzer by reciting "bill 
payer interactivity functionality adapted to detect and respond to communications 
from said bill payers, by at least retrieving information from said database 
corresponding to said bill payers and presenting said information to said bill 
payers in a form requested by said bill payers; and biller interactivity functionality 
adapted to detect and respond to communications from said plurality of billers, by 
at least retrieving information from said database corresponding to said plurality 
of billers and presenting said information to said plurality of billers in a form 
requested by said plurality of billers." The Examiner did not provide any evidence 
of anticipation for these two elements. Therefore, Applicants respectfully traverse 
the Examiner's assertion of anticipation as to an independent Claim 50. 

In view of the distinctions noted and the advantages attendant thereto, it is 
respectfully submitted that Schutzer does not teach every aspect of the claimed 
invention of dependent Claims 10, 17, 18 and independent Claims 1, 41, 45, 46, 
48, and 50 either explicitly or impliedly. Therefore, it is submitted that 
independent Claims 1, 41, 45, 46, 48, and 50 clearly distinguish over Schutzer and 
are patentable thereover. Claims 2-20 are dependent upon Claim 1; Claims 42-44 
are dependent upon Claim 41; Claim 49 is dependent upon Claim 48 and Claim 51 
is dependent upon Claim 50. Claims 2-20, 42-44, 49 and 51 are believed to be 
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patentable along with respective parent claims. 

Independent method Claims 21, 30, 32, 33, 35 and 36 also stand rejected 
under 35 U.S.C. Section 102(e) as being anticipated by Schutzer. Independent 
Claims 30, 32, 33, 35 and 36 have been rewritten in dependent form to improve 
the organization and readability of the claims. Specifically, method Claims 30, 32, 
33, 35 and 36 are now dependent upon Claim 21. 

Claim 21 is directed to a method of providing electronic bill presentment 
and payment and distinguishes over Schutzer by reciting method steps that are 
similar to limitations recited in system Claim 1 as to the use of rules of conversion 
to extract information from billing data and the transformation of information into 
a common document model. Claims 21 distinguishes over Schutzer by reciting, 
inter alia, the steps of "extracting relevant information from billing data, 
corresponding to a plurality of data types, from a plurality of billers using rules of 
conversion"; and "transforming said relevant information into a common 
document model, which common document model is adapted to accommodate 
said relevant information from said plurality of billers and according to said 
plurality of data types." 

As previously discussed hereinabove with respect to Claim 1, "rules of 
conversion" are substantially different from "rules of authentication" because, in 
summary, "rules of conversion" is directed toward a processing functionality for 
parsing biller's data stream, whereas "rules of authentication" act as a login 
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element to provide access verification. The "rules of conversion" of the present 
invention directly affect the function of the parsing engine, common document 
model, and the incoming data itself while the "rules of the certificate of authority" 
from Schutzer are used for compliance. In addition, Schutzer's standard definition 
format merely provides an instructional set of restrictions for converting the bills 
uniformly based on pre-determined templates, whereas Applicants' common 
model document provides a generic conversion process that is not restricted to a 
particular industry, biller, or type of customer. 

In view of the foregoing, it is respectfully submitted that Schutzer does not 
teach every aspect of the claimed invention of independent Claim 21, either 
explicitly or impliedly. Consequently, independent Claim 21 clearly distinguishes 
over Schutzer and is believed to be patentable over Schutzer. Claims 22-30, and 
32-38 which are dependent upon Claim 21, are believed to be patentable with 
parent Claim 21. 

Claim 30 further distinguishes over Schutzer by reciting the method step of 
"detecting and responding to communications from bill payers, by at least (i) 
retrieving information from said database and presenting it to said bill payers in a 
form requested by said bill payers and (ii) altering information in said database 
corresponding to said bill payers according to said communications." As stated 
above with respect to Claims 1 and 10, the present invention allows both billers 
and payers to customize and control the presentation of bills. Schutzer, on the 
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other hand, only allows billers to customize and payers to request bills. Therefore, 
it is respectfully submitted that Schutzer does not teach every aspect of the 
claimed invention of dependent Claim 30, either explicitly or impliedly. 
Consequently, Claim 30 clearly distinguishes over Schutzer and is believed to be 
patentable over Schutzer. 

Claim 35 further distinguishes over Schutzer by reciting "sending and 
receiving communications to and fi"om at least one financial entity and altering and 
storing information according to said communications." The Examiner cited 
Schutzer, 7-7, and column 14, line 26 to column 15, line 2; however, the 
portions of the Schutzer patent referred to by the Examiner do not disclose the step 
as recited in Claim 35. Thus, Schutzer does not teach every aspect of the claimed 
invention of Claim 35, either explicitly or impliedly. Therefore, it is respectfully 
submitted that Claim 35 clearly distinguishes over Schutzer and is believed to be 
patentable thereover. 

Claim 36 further distinguishes over Schutzer by reciting "detecting and 
responding to communications from said bill payers regarding at least one of said 
bills of said bill payers presented by said system, by at least (i) retrieving 
information firom said database and presenting it to said bill payers in a form 
requested by said bill payers and (ii) altering information in said database 
corresponding to said bill payers according to said communications; and sending 
and receiving communications to and from at least one financial entity based at 
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least in part on communications from said bill payers and to alter information in 
said database corresponding to said bills of said bill payers, according at least in 
part to said communications." As stated above with respect to Claims 10 and 18, 
the present invention allows both billers and payers to customize and control the 
presentation of bills, whereas Schutzer only allows billers to customize and payers 
to request bills. Schutzer does not disclose that bill payers can customize and 
control the presentation of bills. Therefore, Claim 36 clearly distinguishes over 
Schutzer and is believed to be patentable thereover. 

Claim 39 is directed to a system for presenting and paying bills and 
distinguishes over Schutzer by reciting, in a manner similar to Claim 1, "an 
extractor functionality which is adapted to parse billing data from a plurality of 
billers using rules of conversion according to which the extractor functionality is 
programmed, corresponding to a plurality of data types, and to provide relevant 
information for further use by said system; a common document model processing 
functionality adapted to transform said relevant information into a common 
document model, which common document model is adapted to accommodate 
said relevant information from said plurality of billers and according to said 
plurality of data types." Therefore, Claim 39 is believed to be patentable for the 
reasons given above with respect to Claim 1 . Claim 40, which is dependent upon 
Claim 39, is believed to be patentable with parent Claim 39. 

New Claims 52-82, of which only Claims 52, 63, and 72 are independent 
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claims, have been added. Claim 52 is directed to a system for presenting and 
paying bills, and distinguishes over Schutzer by reciting elements that are similar 
to limitations recited in system Claim 1 as to the use of rules of conversion for the 
parsing functionality and the common document model. Claim 52 further 
distinguishes over Schutzer by reciting "a modularized input processing engine, 
said input processing engine adapted to preprocess billing data from a plurality of 
billers corresponding to a plurality of data types." The advantage of using a 
modularized processing engine is that this facilitates scalability and expandability. 
For example, if a new form of biller data is encountered or must be dealt with for 
transformation into a form and format, the modularized input processing engine of 
Claim 52 allows for the processing of the new biller data in a modular way (see 
AppUcants* Specification, page 25, lines 17-19). There may be separate engines 
for each new form of data so that the output of each preprocessing engine is ready 
for processing by rules based parsing engine. In other words, because the 
preprocessing of biller data is modularized, new input processing engine can easily 
be integrated to handle new data types. In addition to the modularized input 
element, Schutzer does not disclose, teach or suggest the parsing rules of 
conversion and common document model element as claimed in Claim 52, in a 
manner similar to Claim 1 . Therefore, Claim 52 is believed to be patentable for 
the reasons given above. Claims 53-62 are dependent upon Claim 52 and are 
believed to be patentable with parent Claim 52. 
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Claim 63 is directed to a method of providing electronic billing and 
distinguishes over Schutzer by reciting method steps that are similar to limitations 
recited in system Claim 1 as to the use of mles of conversion to extract 
information from billing data and the transformation of information into a 
common document model. Claim 63 further distinguishes over Schutzer by 
reciting the step of "modularizing the preprocessing of billing data from a plurality 
of billers corresponding to a plurality of data types." As previously discussed with 
respect to Claim 52, modularizing the preprocessing of biller data facilitates 
scalability and expandability without disrupting the present system configuration. 
Therefore, Claim 63 is believed to be patentable for the reasons given above. 
Claims 64-71 are dependent upon Claim 63 and are believed to be patentable with 
parent Claim 63. 

Claim 72 is directed to a system for presenting and paying bills, and 
distinguishes over Schutzer by reciting elements that are similar to limitations 
recited in system Claim 1 as to the use of rules of conversion for the parsing 
functionality and the common document model. Claim 72 further distinguishes 
over Schutzer by reciting "control functionality adapted to allow said plurality of 
billers to control at least one of said parsing functionality, said common document 
model functionality, said database functionality, and said presentation 
functionality." As is stated hereinabove, a common model document model is 
used to transform data and its attribute in to a form that is stored before it is 
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processed. The use of the common model document model in collaboration with 
the control functionality of Claim 72 allows the billers to maintain control over 
their billing data and how it is presented . Therefore, features may vary for each 
bill, including tacking advertisements onto the presented bills. In short, the 
control functionality allows billers to exercise substantial management and 
administrative control over the electronic bill presentment and payment process. 

As disclosed in the Applicants' Application as originally filed. Figures 7-32 
show a series of web pages for the preferred embodiment in which billers are 
enabled to perform a number of functions for managing electronic bill presentment 
' and payment, such as system administration, reporting management, quality 
control, operations management, marketing, and customer service. More 
specifically. Figures 15-18 show that billers can manage an electronic bill 
presentment and payment operations center in which billers may control 
documents received from consumers. Figures 19-21 disclose web pages in which 
billers can manage communications with consumers. Figures 24-32 show that 
billers can support a customer service program with the present invention. 

Schutzer does not disclose, teach or suggest any of the control functionality 
features of Claim 72. Essentially, Schutzer discloses an automatic EBPP system 
in which "flat or formatted" bill files from billers are converted, along with 
enclosures, such as regulatory documents, inserts, and advertisements, to a 
standard bill definition language by the bill service provider (see Schutzer, 
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Column 14, lines 29-35). After decrypting the bill from the bill service provider, 
the consumer service provider presents the bill to the consumer. 

In contrast. Claim 72 provides a control functionality in which billers do 
not lose control over their data once it is received by the system of the present 
invention. In fact, the control functionality empowers billers with unprecedented 
management and administrative control over the EBPP system and process. The 
control functionality may allow billers to, among other things: (1) control parsing 
rules in the input processing engine to accommodate virtual groups according to 
virtual groups functionality; (2) interact with customers while seeing their billing 
records, using customer service and interaction management functionality; (3) 
control how bills or reminders are sent to customers using e-mail and other forms 
of delivery services; (4) control appearance and other characteristics of bill 
presentment in real time using presentment and distribution relationship 
management functionality; (5) get reports and otherwise control the billing process 
(including for example, obtaining parsing reports, getting account receivable 
information or feeds, stopping or starting print or enrollment, and other tasks) 
using biller interaction management; (6) support its own website for presentment 
and payment of bills; and (7) get paid (see Applicants* Specification, page 37, line 
11 to page 38, line 5), 

In view of the distinctions noted and the advantages attendant thereto, it is 
submitted that Claim 72 clearly distinguishes over Schutzer and is believed to be 
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patentable thereover. Claims 73-82 are dependent upon Claim 72 and are believed 
to be patentable with parent Claim 72. 

In summary, Claims 1-30, 32-46, and 48-82 are believed to be allowable 
for the reasons given herein. Accordingly, these claims remain pending following 
entry of this Amendment, and are in condition for allowance at this time. As such. 
Applicants respectfully request entry of the present Amendment and 
reconsideration of the application, with an early and favorable decision being 
solicited. Should the Examiner believe that the prosecution of the application 
could be expedited, the Examiner is requested to call Applicants* undersigned 
attorney at the number listed below. 


Reinhart Boemer Van Deuren, s.c. 
Attn: Linda Gabriel, Docket Clerk 
1000 North Water Street, Suite 2100 
Milwaukee, WI 53202 


Customer No. 22922 



Leonard J. Kalinowski / 
Registration No.: 24,207/ 
Telephone No.: (414) 29i-8359 
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Specification: GROUP 3^00 

Figure 3 shows a more detailed diagram of functionality that processes 
biller data 23 and stores it in database 26 according to a common document 
model/data model. The broad idea that Figure 3 seeks to convey is the notion of 
modularity in taking various types of biller data 23, preprocessing where 
necessary, and parsing according to rules in parsing engine 24 (which may be need 
not be done according to a URDL 25), in order to place that biller data 23 in the 
form of a common document model tree. Think of the common document 
model/data model according to the present invention as a list of every field of data, 
and its attribute (such as, for example, bill number and tag denoting bill number) 
that could occur in any bill desired to be presented by any biller. Not every biller's 
biller data 23 or bill will have all of that information; instead, it only [as] has a 
subset of all data and attributes which could be accommodated by the common 
document model/data model. Accordingly, the biller's subset, which contains data 
and attributes which can be stored and processed according to the model, but not 
all of them, is known as the common document model/data model tree 38. Tree 
38, or fairly close to it, is the output of parsing engine 24. Database loader 40 then 
takes tree 38 and loads it efficiently, effectively, and in conventional fashion in the 
same sort of way various subsets of data are loaded, for example into a global 
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XML data model, onto database 26 which is structured according to common 
document model/storage models of the present invention. 
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MARKED-UP VERSION OF THE CLAIMS 
AS AMENDED IN AMENDMENT A 

1. (Amended) A system for presenting and paying bills, comprising: 

[a.] parsing functionality which is adapted to parse billing data from a 
plurality of billers using rules of conversion according to which [the] said parsing 
functionality is programmed, corresponding to a plurality of data types, and to 
provide relevant information for further use by said system; 

[b.] a common document model processing functionality adapted to 
transform said relevant information into a common document model, [which] said 
common document model is adapted to accommodate said relevant information 
from [the] said plurality of billers and according to [the] said plurality of data 
types; 

[c] a database adapted to store [the] said transformed information from 
[the] said common document model processing functionality; and 

[d.] presentation functionality adapted to retrieve information from said 
database and output at least some of said information via a network for use by bill 
payers. 

2. (Amended) [A] The system according to claim [1 in which the] 1, wherein said 
parsing functionality is adapted to parse data from a print stream of data provided 
by [a biller.] said plurality of billers. 

3. (Amended) [A] The system according to claim [1 in which the] L wherein said 
parsing functionality is adapted to parse data from a data interchange stream of 
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3 data provided by [a biller.] said plurality of billers. 

1 4. (Amended) [A] The system according to claim [1 in which the] L wherein said 

2 parsing functionality is adapted to parse data from a financial data stream provided 

3 by [a biller.] said plurality of billers. 

1 5. (Amended) [A] The system according to claim [1 in which the] L wherein said 

2 presentation functionality is adapted to output information for use by said bill 

3 payers using financial software. 

1 6. (Amended) [A] The system according to claim [1 in which the] L wherein said 

2 presentation functionality is adapted to output information for use by said bill 

3 payers not using financial software. 

1 7. (Amended) [A] The system according to claim [6 in which the] 6, wherein said 

2 presentation functionality is adapted to output information for use by said bill 

3 payers using a browser. 

1 8. (Amended) [A] The system according to claim [1 in which the] L wherein said 

2 presentation functionality employs style sheet functionality in order to render 

3 information in a form suitable for said bill payers. 

1 9. (Amended) [A] The system according to claim [6 in which] 6, wherein 

2 information is provided to said bill payers using markup language. 

1 10. (Amended) [A] The system [for presenting and paying bills, comprising:] 

2 according to claim L further comprising 

3 [a. parsing functionality which is adapted to parse billing data from 

4 a plurality of billers using rules according to which the parsing functionality is 
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5 programmed, corresponding to a plurality of data types, and to provide relevant 

6 information for further use by said system;] 

7 [b. a common document model processing functionality adapted to 

8 transform said relevant information into a common document model, which 

9 common document model is adapted to accommodate said relevant information 

10 from the plurality of billers and according to the plurality of data types;] 

11 [c. a database adapted to store the transformed information from 

12 the common document model processing fiinctionaHty; and] 

13 [d. presentation fiinctionality adapted to retrieve information from said 

14 database and output at least some of said information via a netv^ork for use by bill 

15 payers; and] 

16 [e.] an interactivity fiinctionality adapted to detect and respond to 

17 communications from [a] said bill [payer,] payers, by at least (i) retrieving 

18 information from said database and presenting it to said bill [payer] pavers in a 

19 form requested by said bill [payer;] pavers: and (ii) altering information in said 

20 database corresponding to said bill [payer] payers according to said 

21 communications. ; 

1 11. (Amended) [A] The system [for presenting and paying bills, comprising:] 

2 according to claim 1 , fiirther comprising 

3 [a. parsing fianctionality which is adapted to parse billing data 

4 from a plurality of billers using rules according to which the parsing functionality 

5 is programmed, said billing data corresponding to a plurality of data types, and to 
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6 provide relevant information for further use by said system;] 

7 [b. a common document model processing functionality adapted 

8 to transform said relevant information into a common document model, v^hich 

9 common document model is adapted to accommodate said relevant information 

10 from the plurality of billers and according to the plurality of data types;] 

11 [c. a database adapted to store the transformed information from 

12 [the] said common document model processing functionality; and] 

13 [d. presentation functionality adapted to retrieve information from said 

14 database and output at least some of said information via a network for use by bill 

15 payers; and] 

16 [e.] interactivity functionality adapted to detect and respond to 

17 communications from [a billerj said plurality of billers by at least retrieving 

18 information from said database corresponding to said [biller] plurality of billers 

19 and presenting it to said [biller] plurality of billers in a form requested by said 

20 [biller.] plurality of billers. 

1 12. (Amended) [A] The system according to claim [1 1] iL further comprising 

2 interactivity functionality adapted to detect and respond to communications from 

3 [a] said bill [payer,] payers , by at least (i) retrieving information from said 

4 database and presenting it to said bill [payer] payers in a form requested by said 

5 bill [payer;] payers: and (ii) altering information in said database corresponding to 

6 said bill [payer] payers according to said communications. 

1 13. (Amended) [A] The system [for presenting and paying bills, comprising:] 
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2 according to claim 1. further comprising 

3 [a. parsing functionality which is adapted to parse billing data 

4 from a plurality of billers using rules according to which the parsing functionality 

5 is programmed, said billing data corresponding to a plurality of data types, and to 

6 provide relevant information for further use by said system;] 

7 [b. a common document model processing functionality adapted to 

8 transform said relevant information into a common document model, which 

9 common document model is adapted to accommodate said relevant information 
10 from the plurality of billers and according to the plurality of data types;] 


11 [c. a database adapted to store the transformed information from 

12 the common document model processing functionality; and] 

13 [d. a presentation functionality adapted to retrieve information 

14 from said database and output at least some of said information via a network for 

15 use by bill payers; and] 

16 [e.] a biller interface coupled to said database adapted to allow [a 

17 biller] said plurality of billers to alter appearance and content of bills presented to 

18 said bill payers. 

1 14. (Amended) [A] The system according to claim [13 in which the] 13, wherein 

2 biller interface is further adapted to allow [the biller] said plurality of billers to 

3 communicate with said bill payers regarding said bills. 

1 15. (Amended) [A] The system according to claim [13] 13^ further comprising 

2 interactivity functionality adapted to detect and respond to communications fi-om 
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3 [the biller,] said plurality of billers, by at least retrieving information from said 

4 database corresponding to said [biller] plurality of billers and presenting it to said 

5 [biller] plurality of billers in a form requested by said [biller,] plurality of billers. 

1 16. (Amended) [A] The system according to claim [13] 13^ further comprising 

2 interactivity functionality adapted to detect and respond to communications from 

3 [a] said bill [payer,] payers by at least (i) retrieving information from said database 

4 and presenting it to said bill [payer] payers in a form requested by said bill 

5 [payer;] payers and (ii) altering information in said database corresponding to said 

6 bill [payer] payers according to said communications. 

1 17. (Amended) [A] The system [for presenting and paying bills, comprising:] 

2 according to claim 1 , further comprising 

3 [a. parsing functionality which is adapted to parse billing data 

4 from a plurality of billers using rules according to which the extractor is 

5 programmed, said billing data corresponding to a plurality of data types, and to 

6 provide relevant information for further use by said system;] 

7 [b. a common document model processing functionality adapted to 

8 transform said relevant information into a common document model, which 

9 common document model is adapted to accommodate said relevant information 

10 from the plurality of billers and according to the plurality of data types;] 

11 [c. a database adapted to store the transformed information from 

12 the common document model processing functionality;] 

13 [d. presentation functionality adapted to retrieve information from 
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14 said database and output at least some of said information via a network for use by 

15 bill payers; and] 

16 [e.] a financial source interface adapted to send and receive 

17 communications to and from at least one financial entity and to alter information 

18 in said database according to said financial source communications. 

1 18. (Amended) [A] The system [for presenting and paying bills, comprising:] 

2 according to claim 1, further comprising 

3 [a. parsing functionality which is adapted to parse billing data 


4 from a plurality of billers using rules according to which the extractor is 

5 programmed, said billing data corresponding to a plurality of data types, and to 

6 provide relevant information for further use by said system;] 

7 [b. a common document model processing functionality adapted to 

8 transform said relevant information into a common document model, which 

9 common document model is adapted to accommodate relevant information from 
10 the plurality of billers and according to the plurality of data types;] 


11 [c. a database adapted to store the transformed information from 

12 the common document model processing functionality;] 

13 [d. a presentation functionality adapted to retrieve information 

14 from said database and output at least some of said information via a network for 

15 use by bill payers;] 

16 {e.] interactivity functionality adapted to detect and respond to 

17 communications from [a] said bill [payer] pavers regarding at least one of said 
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18 [bill payer's] bills of said bill pavers presented by said system, by at least (i) 

19 retrieving information from said database and presenting it to said bill [payer] 

20 pavers in a form requested by said bill [payer;] pavers: and (ii) altering 

21 information in said database corresponding to said bill [payer] pavers according to 

22 said communications; and 

23 [f.] a financial source interface adapted to send and receive communications 

24 to and from at least one financial entity based at least in part on communications 

25 from said bill [payer] pavers and to alter information in said database 

26 corresponding to said [bill] bills of said [payer,] pavers, according at least in part 

27 to said financial source communications. 

1 19. (Amended) [A] The system according to claim [18] 18^ fiirther comprising 

2 interactivity fiinctionality adapted to detect and respond to communications from 

3 [a biller,] said pluralitv of billers. bv at least retrieving information from said 

4 database corresponding to said [biller] pluralitv of billers and presenting it to said 

5 [biller] pluralitv of billers in a form requested by said [biller.] pluralitv of billers. 

1 20. (Amended) [A] The system according to claim [18 in which] 18. wherein said 

2 interactivity functionality is adapted to report information to pluralitv of billers 

3 relating at least to status of payment on their bills presented by said system. 

1 21. (Amended) A method of providing electronic bill presentment and payment 

2 services, comprising the steps of: 

3 [a.] extracting relevant information from billing data, 

4 corresponding to a plurality of data types, from a plurality of billers using rules of 
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5 conversion ; 

6 [b.] transforming said relevant information into a common 

7 document model, which conmion document model is adapted to accommodate 

8 said relevant information from [the] said plurality of billers and according to [the] 

9 said plurality of data types; 

10 [c] storing [the] said transformed information from [the] said common 

1 1 document model in a database; and 

12 [d.] retrieving said transformed information from said database and 

13 outputting at least some of said information via a network for use by bill payers. 

1 22. (Amended) The method of claim [21 in which] 21, wherein said billing data is 

2 from a print stream of data provided by [a biller.] said plurality of billers. 

3 

1 23. (Amended) The method of claim [21 in which] 2L wherein said billing data is 

2 from a data interchange stream of data provided by [a biller.] said plurality of 

3 billers. 

1 24. (Amended) The method of claim [21 in which] 2L wherein said billing data is 

2 from a financial data stream provided by [a biller.] said plurality of billers. 

1 25. (Amended) The method of claim [21 in which] 2L wherein said at least some 

2 of said information is output for use by said bill payers using financial software. 

1 26. (Amended) The method of claim [21 in which] 2 1 , wherein said at least some 

2 of said information is output for use by said bill payers not using financial 

3 software. 
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1 27. (Amended) The method of claim [21 in which] 21, wherein said at least some 

2 of said infomiation is output for use by said bill payers using a browser. 

1 28. (Amended) The method of claim [21 in which] 21, wherein said at least some 

2 of said information is output using style sheet functionality in order to render 

3 information in a form suitable for said bill payers. 

1 29. (Amended) The method of claim [26 in which] 26, wherein said at least some 

2 of said information is provided to said bill payers using markup language. 


1 30. (Amended) [A] The method of [providing electronic bill presentment and 

2 payment services,] of claim 21, further comprising the [steps of:] step of 

3 [a. extracting relevant information from billing data, 

4 corresponding to a plurality of data types, from a plurality of billers using rules;] 

5 [b. transforming said relevant information into a common 


6 document model, which common document model is adapted to accommodate 

7 said relevant information from the plurality of billers and according to the plurality 

8 of data types;] 


9 [c. storing the transformed information from the common 

10 document model in a database; ] 

1 1 [d. retrieving said transformed information fi-om said database and 

12 outputting at least some of said information via a network for use by bill payers; 

13 and] 

14 [e.] detecting and responding to communications from [a] bill [payer,] 

15 payers, by at least (i) retrieving information from said database and presenting it to 
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16 said bill [payer] pavers in a form requested by said bill [payer;] pavers and (ii) 

17 altering information in said database corresponding to said bill [payer] pavers 

18 according to said communications. 

1 32. (Amended) [A] The method of [providing electronic bill presentment and 

2 payment services,] claim 2 1 , further comprising the [steps of:] step of 

3 [a.] extracting relevant information from billing data, 

4 corresponding to a plurality of data types, from a plurality of billers using rules of 

5 conversion ; 

6 [b.] transforming said relevant information into a common 

7 document model, which common document model is adapted to accommodate 

8 said relevant information from [the] said plurality of billers and according to [the] 

9 said plurality of data types; 

10 [c] storing [the] said transformed information from [the] said common 

1 1 document model in a database; 

12 [d.] retrieving said transformed information from said database and 

13 outputting at least some of said information via a network for use by bill payers; 

14 and 

15 [e.] detecting and responding to communications from [a bille r,] said 

16 pluralitv of billers, by at least retrieving information from said database 

17 corresponding to said [biller] pluralitv of billers and presenting it to said [biller] 

18 pluralitv of billers in a form requested by said [biller.] pluralitv of billers. 

1 33. (Amended) [A] The method of [providing electronic bill presentment and 
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2 payment services,] of claim 2L further comprising the [steps of:] step of 

3 [a.] extracting relevant information from billing data, 

4 corresponding to a plurality of data types, from a plurality of billers using rules of 

5 conversion : 

6 [b.] transforming said relevant information into a common 


7 document model, which common document model is adapted to accommodate 

8 said relevant information from [the] said plurality of billers and according to [the] 

9 said plurality of data types; 


10 [c] storing [the] said transformed information from [the] said common 

1 1 document model in a database; 

12 [d.] retrieving said transformed information from said database and 

13 outputting at least some of said information via a network for use by bill payers; 

14 and 

15 [e.] allowing [a biller] said plurality of billers to alter appearance and 

16 content of bills presented to said bill payers. 

1 34. (Amended) The method of claim [33] 31, fiirther comprising the step of 

2 allowing [the biller] said plurality of billers to communicate with said bill payers 

3 regarding said bills. 

1 35. (Amended) [A] The method [of providing electronic bill presentment and 

2 payment services J of claim 2 1 . fiirther comprising the [steps of:] step of 

3 [a. extracting relevant information from billing data, corresponding to a 

4 plurality of data types, from a plurality of billers using rules;] 


64 


# # 

5 [b. transforming said relevant information into a common 

6 document model, which common document model is adapted to accommodate 

7 said relevant information from the plurality of billers and according to the plurality 

8 of data types;] 

9 [c. storing the transformed information from the common 

10 document model in a database;] 

1 1 [d. retrieving said transformed information from said database and 

12 outputting at least some of said information via a network for use by bill payers; 

13 and] 

14 [e.] sending and receiving communications to and from at least one 


15 financial entity and altering and storing information according to said 

1 6 communications . 

1 36. (Amended) [A] The method [of providing electronic bill presentment and 

2 payment services,] of claim 21, fiirther comprising the [steps of:] steps of 


3 [a. extracting relevant information from billing data, 

4 corresponding to a plurality of data types, from a plurality of billers using rules;] 

5 [b. transforming said relevant information into a common 

6 document model, which common document model is adapted to accommodate 

7 said relevant information from [the] plurality of billers and according to the 

8 plurality of data types;] 

9 [c. storing the transformed information from the common 

10 document model in a database; and] 
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1 1 [d. retrieving said transformed information from said database and 

12 outputting at least some of said information via a network for use by bill payers;] 

13 [e.] detecting and responding to communications from [a] said bill [payer] 

14 pavers regarding at least one of said [payer's] bills of said bill pavers presented by 

15 said system, by at least (i) retrieving information from said database and 

16 presenting it to said bill [payer] pavers in a form requested by said bill [payer;] 

17 pavers and (ii) altering information in said database corresponding to said bill 

18 [payer] pavers according to said communications; and 

19 [f] sending and receiving communications to and from at least 

20 one financial entity based at least in part on communications from said bill [payer] 

21 pavers and to alter information in said database corresponding to said [bill] bills of 

22 said bill [payer,] pavers, according at least in part to said communications. 

1 37. (Amended) The method of claim [36] 36^ further comprising the step of 

2 detecting and responding to communications from [a biller,] said pluralitv of 

3 billers. by at least retrieving information from said database corresponding to said 

4 [biller] pluralitv of billers and presenting it to said [biller] pluralitv of billers in a 

5 form requested by said [biller.] pluralitv of billers. 

1 38. (Amended) The method of claim [36] 36^ ftirther comprising the step of 

2 reporting information to said pluralitv of billers relating at least to status of 

3 payment on [their] said bills presented to said system. 

1 39. (Amended) A system for presenting and paying bills, comprising: 

2 [a.] an extractor fiinctionality which is adapted to parse billing data 
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3 from a plurality of billers using rules of conversion according to which the 

4 extractor functionality is programmed, corresponding to a plurality of data types, 

5 and to provide relevant information for further use by said system; 

6 [b.] a common document model processing functionality adapted to 

7 transform said relevant information into a common document model, which 

8 common document model is adapted to accommodate said relevant information 

9 from [the] said plurality of billers and according to [the] said plurality of data 

10 types; 

1 1 [c] a database adapted to store [the] said transformed information from 

12 [the] said common document model processing functionality; and 

13 [d.] presentation functionality adapted to retrieve information from 

14 said database and output at least some of said information via a network for use by 

15 bill payers; and 

16 [e.] a bill payer interface coupled to said database adapted to allow 

17 [a] said bill [payer] pavers to pay bills electronically. 

1 40. (Amended) The system of claim [39 in which] 39, wherein said interface is 

2 adapted to allow said bill [payer] pavers to specify the location of said output. 

1 41 . (Amended) A system for presenting and paying bills, comprising: 

2 [a.] parsing functionality which is adapted to parse billing data 

3 from a plurality of billers using rules of conversion according to which [the] said 

4 parsing functionality is programmed, said billing data corresponding to a plurality 

5 of data types, and to provide relevant information for further use by said system; 
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6 [b.] a common document model processing functionality adapted to 

7 transforai said relevant information into a common document model, which 

8 common document model is adapted to accommodate said relevant information 

9 from [the] said plurality of billers and according to [the] said plurality of data 

10 types; 

11 [c] a database adapted to store [the] said transformed information from 

12 [the] said common document model processing fiinctionality; 

13 [d.] a presentation functionality adapted to retrieve information 

14 from said database and output at least some of said information via a network for 

15 use by bill payers; and 

16 [e.] a biller interface coupled to said database adapted to allow [a biller] 

17 said plurality of billers to identify market segments of said bill payers according 

18 to market rules and information retrieved from said database. 

1 42. (Amended) A system according to claim [41 in which the] 4L wherein said 

2 biller interface is further adapted to allow [the biller] said plurality of billers to 

3 alter appearance and content of bills presented to said bill payers based on [the] 

4 said market segments. 

1 43. (Amended) A system according to claim [41 in which the] 41, wherein said 

2 biller interface is further adapted to allow [the biller] said plurality of billers to 

3 send marketing messages to said bill payers based on [the] said market segments. 

1 44. (Amended) A system according to claim [41 in which the] 41, wherein said 

2 biller interface is further adapted to allow [the biller] said plurality of billers to 
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3 communicate with said bill payers regarding said bills based on [the] said market 

4 segments. 

1 45. (Amended) A system for presenting and paying bills, comprising: 

2 [a.] parsing functionality which is adapted to parse billing data 

3 from a plurality of billers using rules of conversion according to which [the] said 

4 parsing functionality is programmed, said billing data corresponding to a plurality 

5 of data types, and to provide relevant information for further use by said system; 

6 [b.] a common document model processing functionality adapted to 

7 transform said relevant information into a conmion document model, which 

8 common document model is adapted to accommodate said relevant information 

9 from [the] said plurality of billers and according to [the] said plurality of data 
10 types; 


1 1 [c] a database adapted to store [the] said transformed information from 

12 [the] said common document model processing functionality; 

13 [d.] a presentation functionality adapted to retrieve information 

14 from said database and output at least some of said information via a network for 

15 use by bill payers; and 

16 [e.] interactivity functionality adapted to detect and respond to 

17 communications from [a biller] said plurality of billers regarding market segments 

18 of said bill payers by retrieving information from said database and altering 

19 appearance and content of bills presented to said bill payers based on said 

20 communications. 
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1 46. (Amended) A system for presenting and paying bills, comprising: 

2 [a.] parsing functionality which is adapted to parse billing data 

3 from a plurality of billers using rules of conversion according to which [the] said 

4 parsing functionality is programmed, said billing data corresponding to a plurality 

5 of data types, and to provide relevant information for further use by said system; 

6 [b.] a common document model processing functionality adapted to 

7 transform said relevant information into a common document model, which 

8 common document model is adapted to accommodate said relevant information 

9 from [the] said plurality of billers and according to [the] said plurality of data 

10 types; 

1 1 [c] a database adapted to store [the] said transformed information from 

12 [the] said common document model processing functionality; 

13 [d.] a presentation functionality adapted to retrieve information 

14 from said database and output at least some of said information via a network for 

15 use by bill payers; and 

16 [e.] interactivity functionality adapted to detect and respond to 

17 communications from [a biller] said plurality of billers regarding market segments 

18 of said bill payers by retrieving information from said database and sending 

19 marketing messages to said bill payers based on said communications, 

1 [47. (Cancelled) A system for presenting and paying bills, comprising: 

2 a. parsing functionality which is adapted to parse billing data 

3 from a plurality of billers using rules according to which the parsing functionality 
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4 is programmed, said billing data corresponding to a plurality of data types, and to 

5 provide relevant information for further use by said system; 

6 b. a common document model processing functionality adapted to 

7 transform said relevant information into a common document model, which 

8 common document model is adapted to acconmiodate said relevant information 

9 from the plurality of billers and according to the plurality of data types; 

10 c. a database adapted to store the transformed information from 

1 1 the common document model processing functionality; 

12 d. a presentation functionality adapted to retrieve information 

13 from said database and output at least some of said information via a network for 

14 use by bill payers; and 

15 e. interactivity functionality adapted to detect and respond to 

16 communications from a biller regarding market segments of bill payers by 

17 retrieving information from said database and altering information in said 

18 database corresponding to bill payers according to said communications,] 

1 48. (Amended) A system for presenting and paying bills, comprising: 

2 [a.] parsing functionality which is adapted to parse billing data 

3 from a plurality of billers using rules of conversion according to which [the] said 

4 parsing functionality is programmed, said billing data corresponding to a plurality 

5 of data types, and to provide relevant information for further use by said system; 

6 [b.] a common document model processing functionality adapted to 

7 transform said relevant information into a common document model, which 
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8 common document model is adapted to accommodate relevant infomiation from 

9 [the] said plurality of billers and according to [the] said plurality of data types; 

10 [c] a database adapted to store [the] said transformed information from 

1 1 [the] said common document model processing functionality; 

12 [d.] a presentation fimctionality adapted to retrieve information 

13 from said database and output at least some of said information via a network for 

14 use by bill payers; and 

15 [e.] an agent interface coupled to said database adapted to allow [an agent] 

16 a plurality of agents having [an] agency [relationship] relationships with [a biller] 

17 said plurality of billers to communicate with said bill payers regarding bills. 

1 49. (Amended) A system according to claim [48 in which the agent] 48, wherein 

2 said plurality of agents interface is further adapted to allow [the agent] said 

3 plurality of agents to communicate with [the biller] said plurality of billers 

4 regarding said bills of said bill payers. 

1 50. (Amended) A system for presenting and paying bills, comprising; 

2 [a.] parsing functionality which is adapted to parse billing data 


3 from a plurality of billers using rules of conversion according to which [the] said 

4 parsing functionality is programmed, said billing data corresponding to a plurality 

5 of data types, and to provide relevant information for further use by said system; 

6 [b.] a common document model processing functionality adapted to 

7 transform said relevant information into a common document model, which 

8 common document model is adapted to accommodate relevant information from 
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9 [the] said plurality of billers and according to [the] said plurality of data types; 

10 [c] a database adapted to store [the] said transformed information from 

1 1 [the] said common document model processing functionality; 

12 [d.] a presentation functionality adapted to retrieve information 

13 from said database and output at least some of said information via a network for 

14 use by bill payers; 

15 [e.] bill payer interactivity functionality adapted to detect and 

16 respond to communications from [a] said bill [payer,] pavers, by at least retrieving 

17 information from said database corresponding to said bill [payer] pavers and 

18 presenting said information to said bill [payer] pavers in a form requested by said 

19 bill [payer;] pavers; and 

20 [f.] biller interactivity functionality adapted to detect and 

21 respond to communications from [a biller,] said pluralitv of billers, by at least 

22 retrieving information from said database corresponding to said [biller] pluralitv of 

23 billers and presenting said information to said [biller] pluralitv of billers in a form 

24 requested by said [biller.] pluralitv of billers. 

1 51. (Amended) A system according to claim [50 in which the] 50, wherein said 

2 biller interactivity functionality and [the] said bill payer interactivity functionality 

3 are further adapted to present substantially the same information to [the biller] said 

4 pluralitv of billers and [the] said bill [payer] pavers in order to allow [the biller] 

5 said pluralitv of billers to interact with [the] said bill [payer] pavers regarding [the] 

6 said same information. 
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1 52. (New Claim) A system for presenting and paving bills, comprising; 

2 a modularized input processing engine, said input processing engine 

3 adapted to preprocess billing data from a plurality of billers corresponding to a 

4 plurality of data types: 

5 a parsing engine including parsing functionality which is adapted to parse 


6 said billing data from a plurality of billers using rules of conversion according to 

7 which said parsing fiinctionality is progranmied, said billing data corresponding to 

8 said plurality of data types, and to provide relevant information for further use by 

9 said system: 


10 a common document model processing fiinctionality adapted to 

11 transform said relevant information into a common document model, which 

12 conmion document model is adapted to accommodate relevant information from 

13 said plurality of billers and according to said plurality of data types: 

14 a database adapted to store said transformed information from 

15 said common document model processing functionality: and 

16 a presentation fiinctionality adapted to retrieve information 


17 from said database and output at least some of said information via a network for 

18 use by bill payers. 

1 53. fNew Claim) The system according to claim 52, fiirther comprising an 

2 interactivity functionality adapted to detect and respond to communications from 

3 said bill payers, by at least (i) retrieving information from said database and 

4 presenting it to said bill payers in a form requested by said bill payers: and (ii) 
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5 altering information in said database corresponding to said bill pavers according to 

6 said communications, 

1 54. fNew Claim) The system according to claim 52. further comprising a financial 

2 source interface adapted to send and receive communications to and fi'om at least 

3 one financial entitv and to alter information in said database according to said 

4 financial source communications. 

1 55. (New Claim) The svstem according to claim 52, further comprising a financial 

2 source interface adapted to send and receive communications to and from at least 

3 one financial entitv based at least in part on communications from said bill pavers 

4 and to alter information in said database corresponding to said bills of said pavers, 

5 according at least in part to said financial source communications. 

1 56.^ CNew Claim) The svstem according to claim 52, further comprising detecting 

2 and responding to communications from bill pavers, bv at least (i) retrieving 

3 information from said database and presenting it to said bill pavers in a form 

4 requested bv said bill pavers and (ii) altering information in said database 

5 corresponding to said bill pavers according to said communications. 

1 57. (New Claim) The svstem according to claim 52, further comprising sending 

2 and receiving communications to and from at least one financial entitv based at 

3 least in part on communications from said bill pavers and to alter information in 

4 said database corresponding to said bills of said bill pavers, according at least in 

5 part to said communications. 

1 58. CNew Claim) The svstem according to claim 52, further comprising a biller 
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2 interface coupled to said database adapted to allow said plurality of billers to 

3 identify market segments of said bill pavers according to market rules and 

4 information retrieved from said database. 

1 59, (New Claim) The system according to claim 52, further comprising 

2 interactivity functionality adapted to detect and respond to communications from 

3 said plurality of billers regarding market segments of said bill payers by retrieving 

4 information from said database and altering appearance and content of bills 

5 presented to said bill payers based on said communications. 

1 60. rNew Claim) The system according to claim 52, further comprising 

2 interactivity functionality adapted to detect and respond to communications from 

3 said plurality of billers regarding market segments of said bill payers by retrieving 

4 information from said database and sending marketing messages to said bill pavers 

5 based on said communications. 

1 61. (New Claim) The system according to claim 52, further comprising an agent 

2 interface coupled to said database adapted to allow a plurality of agents having 

3 agency relationships with said plurality of billers to communicate with said bill 

4 payers regarding bills. 

1 62. fNew Claim) The system according to claim 52. further comprising bill payer 

2 interactivity functionality adapted to detect and respond to communications from 

3 said bill payers, by at least retrieving information from said database 

4 corresponding to said bill payers and presenting said information to said bill 

5 payers in a form requested by said bill payers: and biller interactivity functionality 
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adapted to detect and respond to communications from said plurality of billers. by 
at least retrieving information from said database corresponding to said plurality 
of billers and presenting said information to said plurality of billers in a form 
requested by said plurality of billers. 

63. (New Claim) A method of providing electronic bill presentment and payment 
services, comprising the steps of: 

modularizing the preprocessing of billing data from a plurality of billers 
corresponding to a plurality of data types: 

extracting relevant information from said billing data, corresponding to said 
plurality of data types, from said plurality of billers using rules of conversion: 

transforming said relevant information into a common document model, 
which common document model is adapted to accommodate said relevant 
information from said plurality of billers and according to said plurality of data 
types: 

storing said transformed information from said common 
document model in a database: and 

retrieving said transformed information from said database and 
outputting at least some of said information via a network for use by bill 

payers. 

64. (New Claim) The method of claim 63, wherein said billing data is from a print 
stream of data provided by said plurality of billers. 

65. (New Claim) The method of claim 63, wherein said billing data is from a data 
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2 interchange stream of data provided by said plurality of billers. 

1 66. nSfew Claim) The method of claim 63, wherein said billing data is from a 

2 financial data stream provided by said plurality of billers. 

1 67. (Amended) The method of claim 63. wherein said at least some of said 

2 information is output for use by said bill payers using financial software. 

1 68. rNew Claim) The method of claim 63, wherein said at least some of said 

2 information is output for use by said bill payers not using financial software. 

1 69. (New Claim) The method of claim 63, wherein said at least some of said 

2 information is output for use by said bill payers using a browser. 

1 70. OJew Claim) The method of claim 63, wherein said at least some of said 

2 information is output using style sheet functionality in order to render information 

3 in a form suitable for said bill payers. 

1 71. (New Claim) The method of claim 68, wherein said at least some of said 

2 information is provided to said bill payers using markup language. 

1 72. (New Claim) A system for presenting and paying bills, comprising: 

2 parsing functionality which is adapted to parse billing data from a plurality 

3 of billers using rules of conversion according to which said parsing functionality is 

4 programmed, corresponding to a plurality of data types, and to provide relevant 

5 information for further use by said system: 

6 a common document model processing^functionality adapted to transform 

7 said relevant information into a common document model, said common 


8 document model is adapted to accommodate said relevant information from said 
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9 plurality of billers and according to said plurality of data types; 

10 a database adapted to store said transformed information from 

11 said common document model processing functionality: 

12 presentation functionality adapted to retrieve information from said 

13 database and output at least some of said information via a network for use by bill 

14 payers; and 

15 control functionality adapted to allow said plurality of billers to control at 

16 least one of said parsing functionality, said common document model 

17 functionality, said database functionality, and said presentation functionality. 

1 73. (New Claim) The system according to claim 72, further comprising an 

2 interactivity functionality adapted to detect and respond to communications from 

3 said bill payers, by at least (i) retrieving information from said database and 

4 presenting it to said bill payers in a form requested by said bill payers; and (ii) 

5 altering information in said database corresponding to said bill payers according to 

6 said communications. 

1 74. CNew Claim) The system according to claim 72, further comprising a financial 

2 source interface adapted to send and receive communications to and from at least 

3 one financial entity and to alter information in said database according to said 

4 financial source communications. 

1 75. (New Claim) The system according to claim 72, further comprising a financial 

2 source interface adapted to send and receive communications to and from at least 

3 one financial entity based at least in part on communications from said bill payers 
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4 and to alter information in said database corresponding to said bills of said pavers, 

5 according at least in part to said financial source communications. 

1 76. (New Claim) The system according to claim 72, further comprising detecting 

2 and responding to communications fi'om bill pavers, by at least (i) retrieving 

3 information from said database and presenting it to said bill payers in a form 

4 requested by said bill pavers and (ii) altering information in said database 

5 corresponding to said bill payers according to said communications. 

1 77. flSfew Claim) The system according to claim 72, further comprising sending 

2 and receiving communications to and from at least one financial entity based at 

3 least in part on communications from said bill pavers and to alter information in 

4 said database corresponding to said bills of said bill payers, according at least in 

5 part to said communications. 

1 78. (New Claim) The system according to claim 72, further comprising a biller 

2 interface coupled to said database adapted to allow said plurality of billers to 

3 identify market segments of said bill payers according to market rules and 

4 information retrieved from said database. 

1 79. fNew Claim) The system according to claim 72, further comprising 

2 interactivity functionality adapted to detect and respond to communications from 

3 said plurality of billers regarding market segments of said bill payers by retrieving 

4 information from said database and altering appearance and content of bills 

5 presented to said bill payers based on said communications. 

1 80. (New Claim) The system according to claim 72, further comprising 

80 


2 interactivity functionality adapted to detect and respond to communications from 

3 said plurality of billers regarding market segments of said bill pavers by retrieving 

4 information from said database and sending marketing messages to said bill payers 

5 based on said communications. 

1 81. fNew Claim) The system according to claim 72. fiirther comprising an agent 

2 interface coupled to said database adapted to allow a plurality of agents having 

3 agency relationships v^ith said plurality of billers to communicate with said bill 

4 payers regarding bills. 

1 82. fNew Claim) The system according to claim 72, fiirther comprising bill payer 

2 interactivity fianctionality adapted to detect and respond to communications from 

3 said bill payers, by at least retrieving information from said database 

4 corresponding to said bill payers and presenting said information to said bill 

5 payers in a form requested by said bill pavers: and biller interactivity fiinctionalitv 

6 adapted to detect and respond to communications from said plurality of billers, by 

7 at least retrieving information from said database corresponding to said plurality 

8 of billers and presenting said information to said plurality of billers in a form 

9 requested by said plurality of billers. 
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